\section{Bluetooth} 

\subsection{Scelta dell'architettura e della tecnologia}

La natura mobile dell'applicazione e dei dispositivi sui quali questa viene eseguita richiede che la trasmissione dei dati venga effettuata tramite l'utilizzo di una tecnologia wireless. Un telefono cellulare di fascia alta attualmente sul mercato offre la possibilità di utilizzare il WiFi o il Bluetooth. Dopo le dovute analisi, la scelta è ricatuta sull'utilizzo del Bluetooth, a causa dela necessità di una trasmissione quasi continua e quindi il bisogno di minimizzare il consumo della batteria del dispositivo. Il WiFi avrebbe portato all'esaurimento dell'autonomia del telefono in poche ore di utilizzo.
Al contrario il Bluetooth, che essendo stato pensato per le trasmissioni a brevissimo raggio copre un'area più ristretta, permette di incidere in modo minore sui consumi e di disporre di una maggiore autonomia della batteria.
Il protocollo Bluetooth, inoltre, consente connessioni multiple contemporanee, rendendo l'applicazione più flessibile e le comunicazioni più rapide in ambienti a maggiore densità.


\subsection{Requisiti del protocollo e possibili problemi}

La realizzazione dell'applicazione pone alcuni problemi di rilievo nella gestione delle connessioni con altri dispositivi. Ai fini dell'analisi del dominio applicativo è utile considerare due scenari di utilizzo immaginati come più probabili ed al contempo critici: uno scenario in cui gli incontri tra gli utenti sono casuali ed occasionali, come ad esempio durante un tragitto di spostamento, ed uno scenario caratterizzato dalla presenza di un alto numero di utenti fermi per lungo tempo in uno stesso luogo, come può ad esempio essere una sala d'attesa.
Il primo è caratterizzato da brevissimi tempi di visibilità con la conseguenza di offrire una finestra di comunicazione molto ristretta. Risulta quindi cruciale minimizzare il tempo necessario per il rilevamento di un dispositivo in modo da coprire il maggior di utenti incontrati.
Il secondo invece rischia di causare continui e simultanei tentativi di connessione da parte di tutti i dispositivi, provocando una saturazione delle radio frequenze disponibili che renderebbe molto più disturbato l'invio di dati e porterebbe ad un consumo esagerato di energia.
Dev'essere considerato inoltre che i dispositivi possono essere, e generalmente sono, in continuo movimento, mettendo a rischio la continuit\`a della connessione. È quindi essenziale che il sistema sia in grado di gestire situazioni di inconsistenza senza compromettere i dati esistenti o la corretta esecuzione dell'applicazione.


\subsection{Funzionamento del protocollo di trasferimento messaggi}

Un ciclo di comunicazione tra due dispositivi si compone di cinque fasi principali:
\begin{enumerate}
    \item stabilire una connessione con il dispositivo remoto\footnote{nella fase di connessione vengono identificati i dispositivi con cui si è già recentemente stabilita una connessione}
    \item stabilire la precedenza di trasmissione
    \item inviare/ricevere la lista degli hash dei messaggi (nell'ordine dato dalla precedenza stabilita)
    \item inviare/ricevere i messaggi (nell'ordine dato dalla precedenza stabilita)
    \item chiudere la connessione
\end{enumerate}

Analizziamo nel dettaglio le tre fasi di trasferimento dati.

\subsubsection*{stabilire la precedenza}

È necessario stabilire una precedenza di trasmissione tra i dispositivi, in modo che ognuno sappia a priori quando deve trasmettere e quando deve rimanere in ascolto per la ricezione di nuovi messaggi.
La decisione è stata di assegnare la precedenza sempre al dispositivo che riceve la richiesta di connessione.

\subsubsection*{condividere la lista dei messaggi}

Effettuata la connessione e stabilita una precedenza, bisogna determinare quali messaggi i due dispositivi abbiano in comune prima che questi vengano trasmessi. È bene infatti evitare di inviare dati inutili, al fine di diminuire i tempi di connessione, limitare l'occupazione della banda e il consumo energetico.
Ogni dispositivo quindi compone una lista di hash ottenuti dai messaggi in suo possesso e la trasmette al dispositivo remoto. A questo punto i due dispositivi in comunicazione confrontano le due liste per ottenere i messaggi da trasmettere.

\subsubsection*{condividere i messaggi}

Una volta conosciuti i messaggi da condividere, il dispositivo con la precedenza inizia l'invio. Completato ci\`o si mette in ascolto per ricevere i messaggi del dispositivo remoto. Viceversa, il dispositivo che non ha la precedenza rimarrà in ascolto fino al termine della trasmissione, per poi iniziare l'invio dei propri dati.
I messaggi vengono inseriti nel database, dopodiché la connessione viene chiusa.

\subsection{Problemi tecnici riscontrati dovuti alla tecnologia adottata}

Durante lo sviluppo ed i test dell'applicazione, abbiamo dovuto affrontare numerosi problemi di varia natura, in particolare legati all'utilizzo del Bluetooth. Alcuni di questi sono problemi di tipo architetturale ed è stata sviluppata una strategia per risolvere tali inconvenienti, altri di tipo puramente tecnico dovuti ai dispositivi in uso, alcuni dei quali hanno impedito il completamento ed il test di alcune parti dell'applicazione.
Purtroppo, tali inconvenienti non si limitano all'ambito del Bluetooth, ma riguardano in parte anche l'utilizzo del WiFi.

\subsubsection{L'utilizzo dell'emulatore}

L'SDK di Android contiene numerosi strumenti di sviluppo, tra i quali anche un emulatore software, che permette di eseguire le applicazioni senza dover disporre fin dalle prime fasi di sviluppo di un dispositivo.
All'attuale stato tuttavia, tale strumento non permette l'emulazione del Bluetooth, rendendo essenziale quindi il ricorso a dispositivi esterni.
In modo analogo il WiFi viene dichiarato come supportato, ma nella pratica il suo funzionamento risulta dipendere molto dal tipo di scheda WiFi montata sul computer, rendendo il processo di test aleatorio ed inaffidabile.
L'emulatore si è comunque dimostrato uno strumento insostituibile per lo sviluppo delle parti che non richiedessero l'utilizzo di tecnologie wireless.

\subsubsection{I dispositivi esterni}

È stato possibile testare l'applicazione durante il suo sviluppo su degli smartphone Android, in particolare un \emph{HTC Hero} e un \emph{HTC Magic}.
L'utilizzo di dispositivi esterni non ha purtroppo risolto i problemi posti dall'emulatore. Entrambi i telefoni infatti montavano la versione di Android 1.5.
Per quanto Android disponga di una stack Bluetooth sin dalle primissime release, le API pubbliche per poterne sfruttare le funzioni sono state rese disponibili solamente dalla versione 2.0
Un tentativo di risolvere il problema è stata l'adozione della libreria \emph{backport-android-bluetooth\cite{Backport Android Bluetooth}}, che permette l'accesso alle funzioni Bluetooth utilizzando la tecnica della reflection. Tale espediente ha permesso di proseguire nello sviluppo per le parti riguardanti la ricerca di nuovi dispositivi, ma non è stato in grado di permettere la realizzazione di una connessione funzionante.
Non è stato quindi possibile effettuare fisicamente il trasferimento dei dati, cosa che ha impedito il completamente dell'applicazione.
Il fatto che il problema sia effettivamente imputabile alla versione del sistema operativo dei dispositivi, e non un errore nel codice dell'applicazione, è verificabile scaricando ed eseguendo l'applicazione \emph{BluetoothChat} disponibile sull'\emph{Android Market\cite{Android Market}}, scritta per avere un'esecuzione minimale delle funzioni Bluetooth a fini dimostrativi. Neppure questa applicazione è in grado di istanziare una connessione corretta tra i due dispositivi.
Il programma comunque è stato testato nelle sue parti e, a parte qualche probabile bug di sincronizzazione delle fasi di comunicazione dovuto al fatto che non è stato possibile verificarne il comportamento effettivo, dovrebbe essere funzionante ed utilizzabile.
